Workflow automation software is known, as exemplified by existing U.S. Pat. No. 6,157,934 and the commercial product known as Ultimus Workflow Suite, a product of Ultimus, Inc., the assignee of this application. The entire disclosure of that patent is hereby incorporated herein by reference. The current state-of-the-art in the business process management/workflow automation (BPM/WFA) software is to represent business processes as graphical flowcharts also called “process maps” or “workflow maps.”
A business process (also called simply a “process”) is defined as: “A sequence of structured or semi-structured tasks that are performed in series or in parallel by two or more individuals or application to reach a common goal.” The highlighted words signify the five essential elements of a business process:                i. A process is a “sequence” of tasks indicating the plurality of things that must be accomplished. One task alone does not constitute a process.        ii. The sequence of tasks is “structured or semi-structured.” This signifies that there is some logic to a process. The tasks are not performed on a purely ad hoc basis.        iii. Tasks can be performed in “series or in parallel” based upon the logic of the business process.        iv. There must be at least “two or more” individuals or applications involved as players performing different tasks. If one individual uses an application or form to enter information into a database, that does not constitute a process. Work must flow from one individual or application to another individual or application.        v. The sequence of tasks must have a purpose of reaching a common goal or outcome. This emphasizes the fact that process is geared towards producing results. Merely linking together unrelated tasks into a series of steps does not make a business process.        
FIG. 1 is a block diagram of a process 10 for a simple purchase requisition process. While many of the tasks of FIG. 1 can be accomplished with old fashioned paper and “sneaker-net” routing, modern workflow automation uses a network of computers, and electronic forms. In this example, any employee 12 can initiate a purchase requisition by filling out a form. This is the first step, or task, that must be performed. The supervisor 14 of the employee must then approve the purchase requisition, as represented by the second step in the process. If the supervisor disapproves the purchase, then an e-mail message is sent to the employee informing him of the reasons. If the supervisor approves the purchase, and the amount is less than $1000, the purchase order is sent (step 16) to the buyer 25 since the supervisor is allowed to approve items costing up to $1000. If the amount is more than $1000, the purchase order is sent (step 18) to the company controller, who checks for funds availability and makes a recommendation. It is then sent (20) to the general manager of the company who can approve or disapprove the purchase. Again, if the general manger disapproves it 22, an e-mail is sent to the employee who requested the purchase. If the general manager approves 24, the purchase order is routed to the buyer 25. The buyer can either place an order via telephone and the process ends 26, or she can print 28 a hard copy and mail it to the supplier.
This simple example illustrates the essential elements of a process:                i. The purchase requisition process is a “sequence” of tasks, such as the initial request, supervisor approval, e-mail notification, general manager approval and purchasing. Each step in the process represents a discrete task.        ii. The sequence of tasks is “structured or semi-structured.” The tasks are carried out in accordance with certain logic or rules. For example:                    a. The initial request must always be approved by the initiator's supervisor            b. If the amount is more than $1000, the general manager must approve it.            c. If the request is denied, the requestor must be notified via e-mail.                        iii. The tasks can be performed in “series or in parallel” based upon the logic of the business process. In this example the e-mail notification is sent in parallel, or at the same time the buyer is requested to place the order.        iv. There must be at least “two or more” individuals involved as participants performing different tasks. There are several people involved in the purchase requisition process, including the employee, supervisor, buyer, general manager and controller. In this example we also have two applications involved, namely e-mail and a word processing program, such as Microsoft Word.        v. The sequence of tasks must have a purpose of reaching a common goal or outcome. In this example the purpose of the workflow is to either approve and buy the requested item, or deny it and inform the requestor of the reasons it was denied.        
Based on the definition and this simple example, one can think of many other examples of business processes in every company or organization that fall in the business process category. Some of them are listed in Table 1, but the number and type of processes vary from organization to organization. Suffice it to say that there are a large number of processes, and every organization has its own flavor of each.
TABLE 1Some Typical Workflow ProcessesOrder Processing and FulfillmentChange OrdersPerformance ReviewsPurchase RequisitionsCapital AppropriationsNew Hire ProcessingDefect Tracking and ResolutionNew Product DevelopmentDocument Approval RoutingLeads ManagementMedical/Insurance ClaimsCustomer Care ProcessesExpense ReportsReturn Material AuthorizationsWarranty ManagementInvoice ProcessingEmployee Self-Service ProcessesCorrespondence Tracking
Conventional state-of-the-art BPM/WFA systems are used to automate such business processes using software. The problems with the current approach for automation are as follows:                1. Defining Process Maps: Before a process can be automated, a person or team with a very good knowledge of the business process has to spend a considerable amount of time documenting the current business processes and creating the “flowchart” or process maps. All possible paths or “flows” have to be discovered and included. This effort is very labor intensive, and the time and cost of this effort increases with the complexity of the process. Furthermore, this effort typically requires the use of a business analyst or equivalent, which is an expensive resource. Once the analysts are finished, the process map has to be converted in to a deployable application, which also requires expensive IT personnel.        2. Defining Recipients: The person who performs the task at a step is called the “recipient” or “role”. In addition to the time and cost of laying out the process map, the process designers have to discover and specify who will perform each step in the process. The recipient could be determined by a number of factors:                    i. A specific user performs a task. (E.g. John completes the “supervisor” step)            ii. A specific job function performs a task (E.g. The “CEO” completes the “general manager” step)            iii. A recipient is determined by a reporting relationship (E.g. the “supervisor” step is completed by the person who is the supervisor of the person who started the request)            iv. A group is the recipient of a task (E.g. all the quality mangers must review a document)            v. A recipient is determined dynamically (E.g. the recipient is based upon an “account number” which is entered by a user at a step in the process”            vi. A recipient is based on skill levels (E.g. if the purchase amount is more than $10,000 the purchase is made by John, else it is made by Jane)            vii. A recipient is based on availability (E.g. the buyer step can be performed either by John or Jane, whoever is first available)            viii. A recipient is based on who has the least amount of workload. (E.g. the buyer step is performed by finding out which buyer has the least amount of work to do.)                        Deciding who the recipient is for each step of the process is also a time consuming activity that has to be performed before the process can be activated and is usually performed by a business analyst.        3. Defining Business Rules: In addition to defining the process map and the recipients of each step, it is also important to specify the business rules associated with each step that are to be followed whenever an event occurs. In the example of FIG. 1 described above, a rule is that if the purchase order amount is more than $1000, it must be approved by the general manager, but if it is less the approval of the general manager is not required. The rules tell the software what to do. These rules are generally associated with events that occur for each step. For example, rule described above is evaluated when the event “Supervisor step is complete” occurs. The rules can be conditional or unconditional. All these rules have to be specified for each step in the process. One can imagine that for other than very simple processes, the time, cost and effort required to discover and document all these rules is significant. Furthermore, if the goal is to fully automate these processes, even those events that occur very infrequently require that their rules be specified upfront. Otherwise, if such an event occurs, the automated process will fail.        4. Accommodating Change: Finally, business process maps and their associated rules and recipients are subject to frequent change, as the conditions and the environment of an organization changes. Thus, even after a business process has been automated, the process map, the recipient and the rules frequently have to be changed. These changes involve business analysts as well as technical IT people, since the former knows the process and the latter knows the automation of processes. As shown, the rigidity of prior systems pose problems that limit their usefulness.        